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Sieve Notification Using Presence Information 
Abstract 
This is a further extension to the Sieve mail filtering language 
Notification extension, defining presence information that may be 
checked through the notify_method_capability feature. 
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1. Introduction 


Sometimes, it’s desirable to tailor Sieve [RFC5228] notifications to 


a user’s current situation. Presence information provides some 
information about the user that would be useful to have access to in 
these cases. The Notification extension [RFC5435] defines a 


mechanism to test for presence (the notify_method_capability 
feature), and defines one test for presence (the "online" 
notification-capability, described in Section 5 of RFC 5435). This 
extension defines more presence tests by registering additional 
notification-capability parameters in the IANA registry, allowing 
testing of a wider variety of presence information. 


1.1. Terminology Used in This Document 


The upper-case key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 


2. Testing Presence Information 


This extension uses the notify_method_capability test, as defined in 
the Sieve [RFC5228] Notify extension [RFC5435], to test presence 
information. When a Sieve event occurs (mail arrives) for a user, a 
Sieve script running on behalf of that user can present the user’s 
presence URI (in the "notification-uri" parameter) and test a 
specific item of notification presence as defined below (in the 
"notification-capability" parameter) against one or more values (in 
the "key-list" parameter). 
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This document defines an initial set of items of notification 
presence, which may be specified in the notification-capability 
parameter. It is expected that future extensions will add additional 
presence items derived from diverse sources, including calendar 
information, geographic location, and so on. 


Note that, while the items below are documented as similar to items 
in Extensible Messaging and Presence Protocol (XMPP) [RFC6121], it is 
not the intent that this extension be tied to XMPP, nor to any 
particular source of presence, and flexible implementations will be 
ready for future extensions. Useful informational references for 
presence data and formats include Presence Information Data Format 
(PIDF) [RFC3863], RPID: Rich Presence Extensions to PIDF [RFC4480], 
and GEOPRIV Presence Information Data Format Location Object 
(PIDF-LO) [RFC5491]. 


The script tests the values of notification presence items in the 
key-list parameter. The values that each item may have are specified 
in the list below. Note that in addition to the presence values, any 
item may have the value "unknown" if it is not possible to determine 
the correct presence value of the item. 


If a particular presence item is tested multiple times within the 
same script execution context, implementations MUST present the same 
value each time (for example, by caching the value on first use). 
This provides consistency within a single execution. 


Supported presence items are as follows: 


busy: An indication of whether the user is considered "busy" now 
(the value "yes") or not (the value "no"), or "unknown" if 
it cannot be determined. The meaning of "busy" is left to 
the implementation, and may be a state that’s synthesized 
from other information (including "show", below). 


show: The availability status of the user, formally specified. 
Note that this is similar to the presence element with the 
same name that’s defined in Section 4.7.2.1 of RFC 6121 


[RFC6121]. The value of this item is one of the following: 

away: The user is temporarily away. 

chat: The user is online and actively interested in 
chatting. 

dnd: Do Not Disturb; the user does not wish to be 


disturbed now. 
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offline: The user is offline. 


xa: The user is away for an extended period (xa = 
"extended Away"). 


unknown: The correct presence value could not be determined. 


status: A human-readable description of the user's availability 
status, in natural language. There is no formal definition 
for the values this item may take. It is free-form, and may 
be in any language. Direct comparisons against the value of 
this field are unlikely to be useful; rather, it is provided 
to enable extraction of the value into a variable [RFC5229] 
for use elsewhere (see example 3 in Section 3). Note that 
this is similar to the presence element with the same name 
that’s defined in Section 4.7.2.2 of RFC 6121 [RFC6121], and 
to the <note> element defined in section 4.1.6 of PIDF 
[RFC3863]. 


Because this is a free-form value that might be created 
directly by a user, no value, including "unknown", can have 
any special meaning. If the Sieve processor is unable to 
determine the value of this item, it might be best to leave 
it as an empty string. In any case, it is not meant for 
machine-readable processing, beyond possible XML 
interpretation. 


There is no capability string associated with this extension, but 
this requires support for "enotify" [RFC5435]. If the implementation 
does not support the item being tested (that is, the specified 
notification-capability item is not known to the Sieve interpreter), 
RFC 5435 already specifies that the test fail without an error. 


Although this feature was conceived to assist in notifications, and 
the test requires support of the Sieve Notify feature, it is only a 
condition test, and any Sieve action can appear inside it. There are 
no Sieve actions that conflict with this extension. 


3. Examples 
1. This example will send a notification only if the recipient is 
not "busy". If the test for "busy" is not supported, this 


example will not send a notification. 


George & Leiba Standards Track [Page 4] 


RFC 6132 Sieve Notify: Presence July 2011 


require ["enotify"]; 


if notify_method_capability "xmpp:tim@example.com" "busy" "no" 
{ 
notify :message "You got mail" 
"xmpp:tim@example.com?message; subject=SIEVE"; 


2. This example will send a notification only if the recipient is 
not "busy". If the test for "busy" is not supported, this 
example will send a notification. 


require ["enotify"]; 


if not notify_method_capability "xmpp:tim@example.com" "busy" "yes" 
{ 
notify :message "You got mail" 
"xmpp:tim@example.com?message; subject=SIEVE"; 


3. This example uses the vacation extension [RFC5230] to generate an 
auto-reply [RFC6133] if the sender is in the recipient’s address 
book [RFC6134] and the recipient’s presence shows "extended 


away". The variables extension [RFC5229] is used to extract the 
value of the recipient’s presence status message, which will be 
used in the response to the sender. If the test for "show" is 


not supported, this example will not send an auto-reply. 


require ["extlists", "vacation", "enotify", "variables"]; 
if allof ( 
envelope :list "from" ":addrbook:default", 


notify_method_capability "xmpp:myjid@example.com" "show" "xa" 
pout 

# :matches "*" is used here to extract the value 

if notify_method_capability :matches 


"xmpp:myjid@example.com" "status" "*" { 
set "resp_msg" "S{1}"; 
} else { 
set "resp_msg" "I’m away from email for a while." 
} 
vacation :handle "ext-away" "S{resp_msg}"; 
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4. 


Security Considerations 


Security considerations for Sieve [RFC5228] and the Notify extension 
[RFC5435] apply equally here. In addition, implementations MUST 
ensure that users cannot create scripts that access the presence 
information of others without the proper access controls. 


In some situations, scripts may act on some of the recipient’s 
presence information that the sender of the triggering message is not 
allowed to see. This can be a benefit to the recipient in many 
cases, but it can also present an opportunity for a sender to use 
messages to probe the recipient’s presence (if, for example, messages 
sometimes result in auto-replies, and sometimes do not). Script 
authors should take care in considering this aspect of presence- 
triggered actions. 


It’s possible for a large number of messages to arrive at or around 
the same time and be processed by Sieve scripts that all test 
presence. If many of the users share the same presence server, such 
a burst could put an unexpectedly heavy load on the presence server. 
Implementations might consider providing options for rate limiting, 
or for caching presence tests for periods of time, even across Sieve 
script instances. When caching presence tests, the server must be 
careful not to violate access controls that the presence server might 
have. Thus, cached results MUST NOT be used outside the context in 
which they were retrieved. If, for example, a script running on 
behalf of Adam requests presence information for Barbara, that 
information MAY be cached for a future script running on behalf of 
Adam, but MUST NOT be used to satisfy the same query in a script 
running on behalf of Cindy -- because the presence server will have 
to decide whether Cindy has access to that information. 


IANA Considerations 


This registers each presence item as a notification-capability 
parameter. Future extensions that add new presence items should 
register those items similarly, using the instructions in Section 9.3 
of RFC 5435 [RFC5435]. 


To: iana@iana.org 

Subject: Registration of a new notification-capability parameter 

Capability name: busy 

Description: An indication of whether the user is considered "busy" 
now (the value "yes") or not (the value "no"). The meaning of 
"busy" is left to the implementation, and may be a state that’s 
synthesized from other information. 

Syntax: Has one of the values "yes", "no", or "unknown". The value 
MUST be in lower case. 
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7. 


7. 


Permanent and readily available reference(s): RFC 6132 
Contact information: The Sieve discussion list, <sieve@ietf.org> 


To: iana@iana.org 

Subject: Registration of a new notification-capability parameter 

Capability name: show 

Description: The availability status of the user. This is similar 
to the presence element with the same name that’s defined in 
Section 4.7.2.1 of RFC 6121. 

Syntax: Has one of the values "away", "chat", "dnd", "offline", 
"xa", or “unknown". The value MUST be in lower case. 

Permanent and readily available reference(s): RFC 6132 

Contact information: The Sieve discussion list, <sieve@ietf.org> 


To: iana@iana.org 

Subject: Registration of a new notification-capability parameter 

Capability name: status 

Description: A human-readable description of the user’s availability 
status. This is similar to the presence element with the same 
name that’s defined in Section 4.7.2.2 of RFC 6121. 

Syntax: There is no formal definition for the values this item may 


take. It is free-form and may be in any language, and is meant 
for human consumption. 
Permanent and readily available reference(s): RFC 6132 


Contact information: The Sieve discussion list, <sieve@ietf.org> 
Acknowledgments 


The authors thank Alexey Melnikov for significant early feedback and 
suggestions. 


References 
1. Normative References 


[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
Requirement Levels", BCP 14, RFC 2119, March 1997. 


[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 
Language", RFC 5228, January 2008. 


[RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 
"Sieve Email Filtering: Extension for Notifications", 
RFC 5435, January 2009. 


[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 
Protocol (XMPP): Instant Messaging and Presence", RFC 
6121, March 2011. 


George & Leiba Standards Track [Page 7] 


RFC 6132 Sieve Notify: Presence July 2011 
Ts2 Informative References 

[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 
W., and J. Peterson, "Presence Information Data Format 
(PIDF)", RFC 3863, August 2004. 

[RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. 
Rosenberg, "RPID: Rich Presence Extensions to the Presence 
Information Data Format (PIDF)", RFC 4480, July 2006. 

[RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", 
RFC 5229, January 2008. 

[RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: 
Vacation Extension", RFC 5230, January 2008. 

[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 
Presence Information Data Format Location Object (PIDF-LO) 
Usage Clarification, Considerations, and Recommendations", 
RFC 5491, March 2009. 

[RFC6133] George, R., Leiba, B., and A. Melnikov, "Sieve Email 
Filtering: Use of Presence Information with Auto-Responder 
Functionality", RFC 6134, July 2011. 

[RFC6134] Melnikov, A. and B. Leiba, "Sieve Extension: Externally 


Stored Lists", RFC 6134, July 2011. 


Authors’ Addresses 


Robins George 
Huawei Technologies 


Bangalore, 
India 


Karnataka 560071 


Phone: +91-080-41117676 
EMail: robinsgv@gmail.com 


Barry Leiba 
Huawei Technologies 


Phone: +1 646 827 0648 
EMail: barryleiba@computer.org 
URI: http://internetmessagingtechnology.org/ 


George & Leiba Standards Track [Page 8] 


